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ABSTRACT 



A memory management unit is disclosed for a single-chip 
data processing circuit, such as a smart card. The memory 
management unit (i) partitions a homogeneous memory 
device to achieve heterogeneous memory characteristics for 
various regions of the memory device, and (ii) restricts 
access of installed applications executing in the micropro- 
cessor core to predetermined memory ranges. The memory 
management unit provides two operating modes for the 
processing circuit. In a secure kernel mode, the programmer 
can access all resources of the device including hardware 
control. In an application mode, the memory management 
unit translates the virtual memory address used by the 
software creator into the physical address allocated to the 
application by the operating system in a secure kernel mode 
during installation. The memory management unit imple- 
ments memory address checking using limit registers and 
translates virtual addresses to an absolute memory address 
using offset registers. The memory management unit loads 
limit and offset registers with the appropriate values from an 
application table to ensure that the executing application 
only accesses the designated memory locations. The 
memory management unit can also partition a homogeneous 
memory device, such as an FERAM memory device, to 
achieve heterogeneous memory characteristics normally 
associated with a plurality of memory technologies, such as 
volatile, non-volatile and program storage (ROM) memory 
segments. Once partitioned, the memory management unit 
enforces the appropriate corresponding memory character- 
istics for each heterogeneous memory type. 

18 Claims, 4 Drawing Sheets 
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MEMORY MANAGEMENT METHOD AND partitioned as ROM for storing the software code for only an 
APPARATUS FOR PARTITIONING application. In addition, the Downs system does not provide 
HOMOGENEOUS MEMORY AND a mechanism for configuring the homogeneous memory to 
RESTRICTING ACCESS OF INSTALLED behave like RAM that provides for the temporary storage of 
APPLICATIONS TO PREDETERMINED S information that is cleared after each use. Single-chip 
MEMORY RANGES microprocessors, such as those used in smart cards, increas- 
ingly support multiple functions (applications) and must be 
FIELD OF THE INVENTION able to download an application for immediate execution in 
The present invention relates generally to a memory sll PP ort of a S iven faction. Currently, single-chip micro- 
management system for single-chip data processing circuits, 10 Processors prevent an installed application from improperly 
such as a smart card, and more particularly, to a memory corrupting or otherwise accessing the sensitive information 
management method and apparatus that (i) partitions homo- st0l f on * e cm P ^ software cont , rols - Software- 
geneous memory devices to achieve heterogeneous memory implemented application access control mechanisms, 
characteristics and (ii) restricts access of installed applica- however, rely on the total integrity of the embedded 
tions to predetermined memory ranges. 1S f Aware, including the software that can be loaded in the 

field. 

BACKGROUND OF THE INVENTION Ideally, a system would allow a third party to create an 
Smart cards typically contain a central processing unit application and load it onto a standard card which removes 
(CPU) or a microprocessor to control all processes and „„ lhe conlro1 ov , er ,nte g" tv of the s °f tware allowl "8 
transactions associated with the smart card. The micropro- 20 malicious attacks. This may be overcome for example, by 
cesser is used to increase the security of the device, by programming an interpreter into the card that indirectly 
providing a flexible method to implement complex and executes a command sequence (as opposed to the micro- 
variable algorithms that ensure integrity and access to data processor executing a binary directly). Hns technique, 
stored in non volatile memory. To enable this requirement, „ howeV6r : K <£] KS m , ore Processing power for a given func- 
smart cards contain non-volatile memory, for storing pro- 25 Uon «"* additional code on the device which further 
gram code and changed data, and volatile memory for the ^creases the cost of a cost-sensitive product. A mechanism 
temporary storage of certain information. In conventional » rec P" re ? that ^ memory transaction made 
smart cards, each memory type has been implemented using b , v a loaded . «PPl*ation is hm.ted to the memory areas 



different technologies. 



allocated to it. Furthermore, this mechanism needs to func- 

„ , L1 rrniinw c , . . . „ , . 30 tion independently of the software such that it cannot be 

Byte erasable EEPROM, for example, is typically used to ^ ^ ffls ^ even maUckms goft . 

store non-volatile data, that changes or configures the device ware ^ 

in the field, while Masked-Rom and more recently one-time- ' . . 
programmable read-only memory (OTPROM) is typically A further need exists for a hardware-implemented access 
used to store program code. The data and program code 35 contro1 mechanism that prevents unauthorized applications 
stored in such non-volatile memory will remain in memory, from accessing stored information, such as sensitive data, 
even when the power is removed from the smart card. and the controlling software of smart cards. Hardware- 
Volatile memory is normally implemented as random access implementations of an access control mechanism will maxi- 
memory (RAM). The hardware technologies associated with mize the secunt y of me single-chip microprocessor, and 
each memory type provide desirable security benefits. For 40 allow ^ to be reused > b V the from the 
example, the one-time nature of OTPROM prevents autho- hardware implementation of the device. Furthermore, a 
rized program code from being modified or over-written hardware-implemented access control mechanism allows a 
with unauthorized program code. Likewise, the implemen- secure kernel (operating system) to be embedded into the 
tation of volatile memory as RAM ensures that the tempo- de ™ e > having access rights to features of the device that are 
rarily stored information, such as an encryption key, is 45 demed 10 applications. 

cleared after each use, SUMMARY OF THE INVENTION 

There is an increasing trend, however, to utilize homo- 
geneous memory devices, such as ferroelectric random Generally, a memory management unit is disclosed for a 
access memory (FERAM), in the fabrication of smart cards. single-chip data processing circuit, such as a smart card. The 
FERAM is a nonvolatile memory employing a ferroelectric 50 memory management unit (i) partitions a homogeneous 
material to store the information based on the polarization memory device to achieve heterogeneous memory charac- 
state of the ferroelectric material. Such homogeneous teristics for various regions of the memory device, and (ii) 
memory devices are desirable since they are non-volatile, restricts access of installed applications executing in the 
while providing the speed of RAM, and the density of ROM microprocessor core to predetermined memory ranges, 
while using little energy. The homogeneous nature of such 55 Thus, the memory management unit imposes firewalls 
memory devices, however, eliminates the security benefits between applications and permits hardware checked parti - 
that were previously provided by the various hardware tioning of the memory. 

technologies themselves. Thus, a need exists for the ability Th c memory management unit provides two operating 

to partition such otherwise homogeneous memory devices modes for the processing circuit. Id a secure kernel mode, 

into volatile, non-volatile and program storage (ROM) 60 the programmer can access all resources of the device 

regions with the appropriate corresponding memory char- including hardware control. In an application mode, the 

acteristics. memory management unit translates the virtual memory 

U.S. Pat. No. 5,890,199 to Downs discloses a system for address used by the software creator into the physical 

selectively configuring a homogeneous memory, such as address allocated to the application by the operating system 

FERAM, as read/write memory, read only memory (ROM) 65 in a secure kernel mode during installation. The present 

or a combination of the foregoing. Generally, the Downs invention also ensures that an application does not access 

system allows a single portion of the memory array to be memory outside of the memory mapped to the application 
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by the software when in secure kernel mode. Any illegal person of ordinary skill. In addition, while the present 

memory accesses attempted by an application will cause a invention is illustrated in a smart card environment, the 

trap, and in one embodiment, the memory management unit present invention applies to any single-chip data processing 

restarts the microprocessor in a secure kernel mode, option- circuit, as would be apparent to a person of ordinary skill in 

ally setting flags to permit a system programmer to imple- 5 the art. 

ment an appropriate mechanism to deal with the exception. According to a feature of the present invention, the 

An application table records the memory demands of each memory management unit 200, discussed further below in 

application that is installed on the single-chip data process- conjunction with FIG. 2, imposes firewalls between appli- 

ing circuit, such as the volatile, no n -volatile and program cations and thereby permits hardware checked partitioning 

storage (OTPROM) memory requirements of each applica- 10 of the memory. Thus, an application has limited access to 

tion. The memory management unit implements memory only a predetermined memory range. As discussed further 

address checking using limit registers and translates virtual below, the memory management unit 200 performs memory 

addresses to an absolute memory address using offset reg- address checking and translates addresses based on user- 

isters. Once the appropriate memory areas have been alio- specified criteria. 

cated to each application program, the memory management ^ According to another feature of the invention, the 

unit loads limit and offset registers with the appropriate memory management unit 200 provides two operating 

values from the application table to ensure that the executing modes for the microprocessor 110. In a secure kernel mode, 

application only accesses the designated memory locations. the programmer can access all resources of the device 

According to another aspect of the invention, the memory including hardware control. In an application mode, the 

management unit partitioas a homogeneous memory device, 20 memory management unit 200 translates the virtual memory 

such as an FERAM memory device, to achieve heteroge- address used by the software creator into the physical 

neous memory characteristics normally associated with a address allocated to the application by the operating system 

plurality of memory technologies, such as volatile, non- in a secure kernel mode during installation. The present 

volatile and program storage (ROM) memory segments. invention also ensures that an application does not access 

Once partitioned, the memory management unit enforces the 25 memory outside of the memory mapped to the application 

appropriate corresponding memory characteristics for each by the software when in secure kernel mode. Any illegal 

heterogeneous memory type. A memory partition control memory accesses attempted by an application will cause a 

logic is programmed with the required partitioning associ- trap, and in one embodiment, the memory management unit 

ated with each portion of the homogeneous memory in order 200 restarts the microprocessor 10 in a secure kernel mode, 

that the homogeneous memory behaves like volatile, non- 30 optionally setting flags to permit a system programmer to 

volatile and program storage (OTPROM) memory implement an appropriate mechanism to deal with the 

technologies, as desired. exception. 

A more complete understanding of the present invention, In this manner, an exception is identified if an application 

as well as further features and advantages of the present 35 is written with the accidental or specific intention of com- 

invention, will be obtained by reference to the following promising the security of the smart card, by accessing stored 

detailed description and drawings. data, code or by manipulating the hardware to indirectly 

influence the operation of the chip. The memory manage- 

BRIEF DESCRIPTION OF THE DRAWINGS men t unit 200 limits the application to the allocated program 

™„ . . , * * ui t a ' n * . • i ,n code and data areas. Any other references result in termi- 

FIG. 1 is a schematic block diagram illustrating a single- 40 J 

. . , , . • % u * a fu * nation of the application and flagging the secure kernel that 

chip data processing circu.t, such as a smart card that an ™ has bte Tmzfc. Tlius, each applica- 

includes a memory management unit .n accordance wnh the ^ . g from H, ^ applicationSi the harfw ** and 

presen inven ion, ^ secure kernel. In an implementation where application 

FIG. 2 is a schematic block diagram of an exemplary isolation is not needed, the security mechanism acts as a 

hardware-implementation of the memory management unit 45 genend protection unil trapping software errors, 

of FIG. 1, According to a further feature of the present invention, the 

FIG. 3 is a sample table from the exemplary application mem0 ry management unit 200 partitions a homogeneous 

table of FIG. 2; and memory device, such as an FERAM memory device, to 

FIG. 4 is a schematic block diagram illustrating the 50 achieve heterogeneous memory characteristics normally 

memory partition control logic of FIG. 2. associated with a plurality of memory technologies, such as 

volatile, non-volatile and program storage (ROM) memory 

DETAILED DESCRIPTION segments. Once partitioned, the memory management unit 

FIG. 1 illustrates a single-chip data processing circuit 100, 200 enforces the appropriate corresponding memory char- 
such as a smart card, that includes a microprocessor core 55 acteristics for each heterogeneous memory type. 
110, memory devices 120, 130 and a memory management FIG. 2 provides a schematic block diagram of an exem- 
unit 200 that interfaces between the microprocessor core 110 plary hardware-implementation of the memory management 
and the memory devices 120, 130 for memory access unit 200. As previously indicated, the memory management 
operations. In accordance with the present invention, the unit 200 (i) partitions a homogeneous memory device to 
memory management unit 200 (i) partitions a homogeneous 60 achieve heterogeneous memory characteristics for various 
memory device to achieve heterogeneous memory charac- regions of the memory device, and (ii) restricts access of 
teristics for various regions of the memory device, and (ii) installed applications executing in the microprocessor core 
restricts access of installed applications executing in the 110 to predetermined memory ranges. As shown in FIG. 2 
microprocessor core 110 to predetermined memory ranges. and discussed further below in conjunction with FIG. 4, the 
It is noted that each of these two features are independent, 65 memory management unit 200 includes a section for 
and may be selectively and separately implemented in the memory partition control logic 400. Generally, the memory 
memory management unit 200, as would be apparent to a partition control logic 400 is programmed with the required 
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partitioning associated with each portion of the homoge- 
neous memory in order that the homogeneous memory 
behaves like volatile, non-volatile and program storage 
(OTPROM) memory technologies, as desired. An applica- 
tion would normally be allocated different memory areas for 
code and data, and the data area can be further divided into 
a volatile portion, for scratch pad operations, and non- 
volatile storage areas. 

In addition, the memory management unit 200 includes an 
application table 300, discussed further below in conjunc- 
tion with FIG. 3. Generally, the application table 300 records 
the memory demands of each application that is installed on 
the single-chip data processing circuit 100. For example, the 
application table 300 indicates the volatile, non-volatile and 
program storage (OTPROM) memory requirements of each 
application. The application table 300 is generated by the 
microprocessor 110 when operating in a secure kernel mode, 
as each application is installed. The kernel allocates the 
appropriate memory areas to each application program. 

Once the appropriate memory areas have been allocated 
to each application program, the memory management unit 
200 shown in FIG. 2 can load the limit and offset registers 
230-232, 240-242, discussed below, with the appropriate 
values from the application table 300 to ensure that the 
executing application only accesses the designated memory 
locations. Generally, the memory management unit 200 
implements memory address checking using the limit reg- 
isters 230-232 and translates addresses to an absolute 
memory address using the offset registers 240-242, 

In addition to restricting access of installed applications 
executing in the microprocessor core 110 to predetermined 
memory ranges, the memory management unit 200 also 
translates addresses between the virtual memory address 
used by the software programmer into the physical address 
allocated to the application by the operating system in a 
secure kernel mode, before it hands over execution to the 
application code. It is noted that when programming the 
illustrative 8051 microprocessor, a software programmer 
starts with a code space starting at an address of 0, and a data 
space starting at an address of 0. Furthermore, the size of the 
code and data space is a variable corresponding to the 
required resource of a given application. 

Again, the application has the appropriate volatile, non- 
volatile and program storage (OTPROM) memory alloca- 
tions that are translated and checked by the memory man- 
agement unit 200, in a manner described below, such that 
attempts to access memory outside the designated memory 
area will result in the application being terminated. The 
kernel will be restarted and the offending trapped access, 
being stored for interrogation by the kernel. 

The hardware memory -mapping scheme and out of area 
protection hardware mechanism is shown in FIG. 2. In the 
illustrative 8051 microprocessor, only one application is 
active at any time, so only one set of mapping logic is 
required, as shown in FIG. 2. Thus, the microprocessor core 
110 must implement context switching in a multi-function 
environment, as would be apparent to a person of ordinary 
skill. As previously indicated, the memory management unit 
200 includes a pair of limit and offset registers, such as the 
registers 230-232, 240-242, respectively, for each memory 
technology that is managed by the memory management 
unit 200. 

Before an application is started, the associated memory 
requirements are retrieved from the application table 300 by 
the secure operating system running in the kernel mode. The 
associated memory requirements are loaded into the corre- 
sponding limit and offset registers 230-232, 240-242. 

Thereafter, the kernel loads the code application offset 
register (COR) 240 with the address of where the application 



program code is stored in memory. The kernel then loads the 
code application limit register (CLR) 230 with the size of the 
application code space. Similarly, the data space can be 
defined as a block of memory, whose si7x is the sum of the 

5 sizes of both the volatile and non-volatile memory, allocated 
to that application. Thus, the kernel loads the data limit 
register (DLR) 231 with the size of the data space (both the 
volatile and nonvolatile memory). The size of the allocated 
volatile memory is loaded into the volatile data limit register 
(VDLR) 232, and the base address to be used for the scratch 

10 pad memory (RAM) is loaded into the volatile data offset 
register (VDOR) 241. Finally, the base address to be used for 
non- volatile storage (EEPROM) allocated to the application 
is loaded into the non volatile offset register (NVOR) 242. 
In one implementation, the memory protection mecha- 

15 nism checks the virtual memory addresses assigned by the 
programmer, as opposed to the absolute addresses allocated 
by the kernel. Thus, the illegal access mechanism is 
simplified, as an illegal memory access is identified when an 
access is made to a location having a virtual address that is 

20 greater than the value contained in the appropriate limit 
register. Thus, as shown in FIG. 2, the memory management 
unit 200 contains comparators 250, 255 for comparing the 
virtual address issued by the microprocessor core 210, to the 
value contained in the appropriate limit register 230-232. If 

25 the application is attempting an unauthorized memory 
access, the corresponding comparator 250, 255 will set an 
out-of-bounds trap. 

If the application is attempting an authorized memory 
access, the corresponding comparator 250, 255 will enable 

30 the appropriate offset register 240-242, and the value from 
the offset register will be added by an adder 260 to the virtual 
address issued by the microprocessor core 210. In one 
preferred implementation, the limit and offset registers 
230-232, 240-242 and the comparators 250, 255 are fabri- 
cated using known tamper-resistant technologies to preclude 

35 physical security attack. 

FIG. 3 illustrates an exemplary application table 300 that 
stores information on each application installed on the 
single-chip data processing circuit 100, including the 
memory demands of each installed application. As shown in 

40 FIG. 3, the application table 300 indicates the volatile, 
non-volatile and program storage (OTPROM) memory 
requirements of each application. The application table 300 
may be generated by the microprocessor 110 when operating 
in a secure kernel mode, as each application is installed. The 

45 kernel allocates the appropriate memory areas to each appli- 
cation program. 

The application table 300 maintains a plurality of records, 
such as records 305-315, each associated with a different 
application. For each application identifier in field 320, the 

50 application table 300 includes the base address of where the 
application program code is stored in memory, and the 
corresponding size of the application code space in fields 
325 and 330, respectively. In addition, the application table 
300 indicates the total size of the data space in field 335 (sum 

55 of both the volatile and non-volatile memory), with the size 
of the allocated volatile memory stored in field 340, the base 
address for the scratch pad memory (RAM) in field 345, and 
the base address for non-volatile storage (EEPROM) is 
recorded in field 350. As previously indicated, when an 
application becomes active, each of the corresponding 

60 memory range values from fields 325 through 350 are 
retrieved and loaded into the appropriate limit and offset 
registers 230-232, 240-242, respectively. 

FIG. 4 illustrates the memory partition control logic 400 
for a homogeneous memory array 450. As previously 

65 indicated, the memory partition control logic 400 contains 
registers associated with each portion of the homogeneous 
memory in order that the homogeneous memory behaves 
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like volatile, non- volatile and program storage (OTPROM) 
memory technologies, as desired. An application would 
normally be allocated different memory areas for code and 
data, and the data area can be further divided into a volatile 
portion, for scratchpad operations, and non-volatile storage 
areas. FERAM is inherently a non-volatile array. In other 
words, FERAM can be changed many times and holds the 
last written value, even when powered down, in a manner 
similar to EEPROM. Thus, it is unnecessary to force 
EEPROM-behavior onto the FERAM to achieve a non- 
volatile array. 

To create a volatile array using the non-volatile FERAM 
array, erase circuitry 410, 430 is added, for example, by 
writing 0's to each address, or using a block erase feature 
built into the array that writes 0's to many addresses in 



2. The single-chip data processing circuit of claim 1, 
wherein said memory technologies include a read only 
memory technology with limited programmability. 

3. The single-chip data processing circuit of claim 1, 
wherein said memory technologies include a non-volatile 
memory technology. 

4. The single-chip data processing circuit of claim 1, 
wherein said memory management unit includes block erase 
logic to achieve volatile memory characteristics. 

5. The single-chip data processing circuit of claim 1, 
wherein said memory management unit includes lock-write 
erase logic to achieve memory characteristics with limited 
programmability. 

6. The single-chip data processing circuit of claim 1, 
wherein said memory management unit further comprises a 



parallel. The erase circuitry 410, 430 records the upper and 15 register for storing a base memory address corresponding to 

lower limits of the memory range that should behave like a a location where a non-volatile memory region begins, 

volatile array. Similarly, to ensure that the code is not written The single-chip data processing circuit of claim 1, 

to, a write inhibit has to be forced onto the memory array wherein said memory management unit further composes a 

using lock-write circuitry 420, 440. The lock-write circuitry register for storing a memory address corresponding to a 

420, 440 records the upper and lower limits of the memory 20 location where a non-volatile memory region ends, 

range that should behave like program storage (OTPROM) ° ^ " ~ L " J "*~ * 
memory. 

Once the application space has been setup by the secure 
kernel, defined areas of the homogeneous array need to 

behave in the appropriate manner. This can be achieved by 25 
mapping the erase logic using the same memory definitions 



used to define the volatile memory area for applications. 
Before an application is started (or after or both), the erase 
mechanism is enabled, ensuring that an application when 
started can see no residual values left over by a previous 
application or the kernel, that may have used the designated 
block. Similarly, the same simple mechanism can be used to 
enforce a write -lock on the area designated as the code space 
for the application to prevent the application from modifying 
its code to cause potential unknown conditions and hence 
revealing secure aspects of the device. 

The application RAM area is defined by parameters 
loaded into erase circuitry 430. Typically, the value loaded 
into the erase circuitry 430 would be the physical address 
location within the FERAM memory array and the size of 
the allocated memory. The block erase logic 410, when 
activated, is constrained by the erase circuitry 430 to erase 
the predefined area. The same principle is used to obtain 
OTP characteristics. OTP partitioning is defined by the 
lock-write circuitry 440, which allocates an area of the same 



30 



35 



50 



memory array once parameters are loaded. The lock write 45 limited jirogrammability 
logic 420 removes the write capability for the area defined 
in the lock-write circuitry 440 giving the area the same 
characteristics as OTP memory. 

It is to be understood that the embodiments and variations 
shown and described herein are merely illustrative of the 
principles of this invention and that various modifications 
may be implemented by those skilled in the art without 
departing from the scope and spirit of the invention, 
I claim: 

1. a single-chip data processing circuit, comprising: 

a processor for executing a plurality of applications; 

a homogeneous memory device; and 

a memory management unit for (i) partitioning said 
homogeneous memory device for each of said plurality 
of applications to achieve memory characteristics asso- 
ciated with a plurality of memory technologies, includ- 
ing a volatile memory technology, (ii) recording for 
each of said applications a range for an assigned 
heterogeneous memory type corresponding to each of 
said partitions, and (iii) enforcing memory character- 
istics for a heterogeneous memory type corresponding 
to each of said partitions for each of said applications. 



8. The single-chip data processing circuit of claim 1, 
wherein said memory management unit further comprises a 
register for storing a base memory address corresponding to 
a location where a volatile memory region begins. 

9. The single-chip data processing circuit of claim 1, 
wherein said memory management unit further comprises a 
register for storing a memory address corresponding to a 
location where a volatile memory region ends. 

10. A method for partitioning a homogeneous memory 
device to achieve heterogeneous memory characteristics for 
various regions of the memory device for a plurality of 
applications, comprising the steps of: 

partitioning said homogeneous memory device to achieve 
memory characteristics associated with a plurality of 
memory technologies, including a volatile memory 
technology; 

recording for each of said applications a range for an 

assigned heterogeneous memory type corresponding to 

each of said partitions; and 
enforcing memory characteristics for a heterogeneous 

memory type corresponding to each of said partitions 

for each of said applications. 

11. The method of claim 10, wherein said memory tech- 
nologies include a read only memory technology with 



12. The method of claim 10, wherein said memory 
technologies include a non-volatile memory technology. 

13. The method of claim 10, further comprising the step 
of erasing a partition of said homogeneous memory device 
to achieve volatile memory characteristics. 

14. The method of claim 10, further comprising the step 
of preventing write operations in a partition to achieve 
memory characteristics with limited programmability. 

15. The method of claim 10, further comprising the step 
55 of storing a base memory address corresponding to a loca- 
tion where a non-volatile memory region begins. 

16. The method of claim 10, further comprising the step 
of storing a memory address corresponding to a location 
where a non -volatile memory region ends. 

60 17. The method of claim 10, further comprising the step 
of storing a base memory address corresponding to a loca- 
tion where a volatile memory region begins. 

18. The method of claim 10, further comprising the step 
of storing a memory address corresponding to a location 
65 where a volatile memory region ends. 
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